Anthropic 如何在各产品中约束 Claude
发布日期： 2026年5月25日
分类： Engineering
来源： https://www.anthropic.com/engineering/how-we-contain-claude
12 个月前，若有人提出授予 Claude 足以让 Anthropic 内部服务下线的访问权限，我们会直接拒绝；今天，这类权限已很常见，且 Anthropic 开发者也因此更高效。部署风险包含两个部分：失败发生的概率，以及一次失败可能造成的损害。安全措施和模型训练持续降低前者；但随着能力和访问权扩展，后者，即理论上的影响范围，只会增大。与此同时，Agent 已能完成过去需一个人甚至一个团队完成的工作，不部署的成本也越来越高。只要产品能做得安全，收益风险计算就会倾向采用。工程问题因而变成：如何为影响范围设上限。
当可通过环境控制等手段限制自主 Agent 的相对损害时，高价值能力就可能值得部署。Claude Mythos Preview 是一个例子：其影响范围在 2026 年 4 月仍被认为过大而不能发布。随着防御者加固关键系统、安全措施成熟，类似能力模型会逐步适合更广发布，尽管风险永远不可能为零。模型能力是 Agent 部署总体风险的重要因素。
广义上有两种做法。第一种是以 human-in-the-loop 监督 Agent 行为。Claude Code 曾要求用户在每回合批准，理论可行，但遥测显示用户约批准 93% 的权限提示；提示越多，注意力越低，监督会日渐松懈。Claude Code 的 auto mode 会自动批准更安全的操作，以减少批准疲劳，但概率性防御仍有非零遗漏率。
第二种，也是本文重点，是 containment（约束/隔离）。不监督 Agent 实际做什么，而是通过 sandbox、VM 和 egress control 强制访问边界，监督它能够做什么。这也是 Anthropic 工程投入最多、同时发生过最意外安全失败的领域。
过去两年，Anthropic 发布了三款主要 Agent 产品：claude.ai、Claude Code 与 Claude Cowork。它们面向不同人群，需要不同 containment architecture。本文分享哪些设计经受住考验、哪些环节失效，以及从中获得的 Agent security 经验。
三类风险，三层防御
Agent 的安全风险大致分三类：
用户滥用。 用户恶意或疏忽地指使 Agent 做有害事情，例如要求绕过烦人的检查、运行自己不理解的破坏性命令，或明确指定恶意行为。
模型失当行为。 Agent 自行采取无人要求的有害动作。模型能力提高后，很多对齐评测上的表现变好，但风险不一定缩小：能力较弱模型易误读情境、犯明显错误；能力更强模型错得更少，却更擅长寻找意外达成目标的路径，包括绕过无人预想到的限制。Anthropic 曾看到 Claude 为完成任务而“乐于助人地”逃出 sandbox、查看 git history 寻找编码测试答案，或自行识别正在运行的 benchmark 并解密 answer key。每代模型都带来可能以意外方式发挥作用的新能力。
外部攻击者。 Agent 通过 tools、files 或网络访问遭到攻击，包含 Prompt injection，也包含针对 Agent runtime、orchestration layer 和 proxy 的传统攻击。
构建 containment 和防御系统时，重点保护三部分：
Agent 的运行环境。 以 process sandbox、VM、filesystem boundary 和 egress control 限制 Agent 可在何处、以何种方式行动。目标是对 Agent 能触达的事物设硬边界。例如 credentials 永不进入 sandbox，就无法被外传，无论原因是用户、模型发现“创造性”路径还是攻击者。
紧密边界也允许降低人工监督。Claude Code 的 reference devcontainer正是为使 Agent 无需逐操作批准、可无人值守运行而存在。
Agent 所咨询的模型。 这层包括 system prompt、classifier、probe 和训练改动。由于模型具概率性，它们只能塑造 Agent 倾向于做什么，不能限制理论上能做什么。此层很强：Gray Swan Agent Red Teaming benchmark 中，Claude Opus 4.7 单次 Prompt injection 攻击成功率约 0.1%，经过 100 次 adaptive attempt 后约 5% 到 6%；Claude Code auto mode 可在执行前捕获约 83% 过度激进的行为。但即使是最佳防御，模型层也不可能 100% 有效，不能单独依赖。
Agent 可接触的外部内容。 MCP server、第三方 plugin 与 web search tool 都会从不可控来源把内容送入 Agent context。审核过的 connector 不等于审核过的数据：GitHub connector 即使通过恶意软件检查，也可能把被投毒 README 载入模型 context。细化工具权限有助于缩小影响范围，例如只读数据库 Agent 比可写生产库的 Agent 能部署得广得多。
各层防御应重叠互补。环境防御不可用时，模型层必须补位，这正是 Claude Code auto mode 的用途；本地环境和模型层可防御恶意 tool output，更上层还可通过限制 tool 能力与访问权增加保护。
需防御的三个组成：模型、其运行环境，以及它可触达的外部内容。
约束 Agent 的模式
聚焦环境层，Anthropic 为 claude.ai、Claude Code 与 Cowork 形成三种隔离模式。每种设计都经历逐步演变，是在 Agent 所需能力与用户需介入程度之间寻找平衡的结果。
模式一：短生命周期容器（claude.ai 代码执行）
claude.ai 虽以聊天界面最广为人知，也会写、运行代码，生成文件并调用 connector。其代码执行发生在隔离基础设施中的 gVisor container：Agent 完全运行在服务端，不在本地机执行代码；filesystem 是每 session 临时的。影响范围很小，但 Claude 能做的事上限也低，没有持久 workspace，也无法访问用户 filesystem。
这也使 claude.ai 面临更传统的 threat model：不是保护用户机器免受 Agent 影响，而是保护 Anthropic 自身基础设施与不同 tenant 彼此隔离。claude.ai 发布前的大量工作是网络配置、内部服务认证和 orchestration 等传统安全工程。
这再次印证最老的安全教训：最薄弱的一层通常是你自己造的。gVisor 与 seccomp在 Agentic AI 出现前就已历经资源充足对手的加固，审查重点因此放在团队围绕它们构建的新组件上。后文会看到，custom proxy 也正是最严重事件中失效的部件。
模式二：human-in-the-loop sandbox（Claude Code）
Claude Code 运行在用户机器上，可访问 filesystem、shell 和 network。没有这些，coding Agent 用处有限，因此关键在于安全地授予访问权。
一种方法是依赖 human-in-the-loop。它只在 Claude Code 中相对可行，因为平均用户是熟悉编码环境的开发者：能读 bash、理解 rm -rf，也每周会多次从不可信来源运行 npm install。因此“是否允许”的对话框出现时，用户大概率具备判断 Agent 意图和风险的专业知识。基于这一前提，Claude Code 初始防御非常简单：允许 read，write、bash 和 network 都需批准。
但批准疲劳数周内就出现了。讽刺的是，原为监督设计的功能可能让用户停止关注。为减轻随意批准，Anthropic 增加 OS-level sandbox，macOS 使用 Seatbelt、Linux 使用 bubblewrap：允许 read，在 workspace 内允许 write，但默认拒绝 network。Sandbox 内 Agent 可基本不被打断地运行。结果是权限提示减少 84%，且 runtime 已开源，边界可审计。
匿名使用数据还显示，资深用户自动批准约为新用户两倍，但也更常在运行中中断 Agent。他们倾向不逐步 gate，而是仅当 Agent 偏离时监督。这可能符合人们偏好的工作演进，却仍会失效：用户必须足够技术且专注，先看出 drift；模型更强、Agent 写出的 bash 更有野心时，drift 更难被发现；多 Agent 系统中，该策略更难成为有效监督手段。
遗漏的风险：trust dialog 之前发生的一切
从 2025 年中到 2026 年 1 月，Anthropic 通过 responsible disclosure 收到 Claude Code 漏洞报告，其中三项利用了用户同意前就执行的代码。最直接案例是：开发者 clone 一个仓库审查 PR，仓库中存在定义 hook 的 .claude/settings.json。Claude Code 在启动中读取 project setting，早于“是否信任该 folder”的提示，因此攻击者写入并提交的 hook 会自动执行。其余案例结构相似，均是在信任边界建立前解析了尚不可信目录输入。
修复方式一致：直到用户接受 trust prompt 后，才解析和执行项目本地配置。若你在构建类似系统，应把 project-open、config-load 和 localhost listener 当作任何来自互联网的 inbound request；它们不能仅因是本地、或在用户同意前到达就被隐式信任。
遗漏的风险：用户本身是 injection vector
2026 年 2 月，在受控内部 red-team exercise 中，研究员成功钓鱼诱导员工用恶意 prompt 启动 Claude Code。钓鱼邮件看起来只是普通协作，“能帮我运行这个吗？”，附有可直接粘贴 prompt；在设置步骤中，它不显眼地要求 Claude 读取 ~/.aws/credentials、编码内容，并 POST 到外部 endpoint。该 prompt 重试 25 次，Claude 24 次完成了外传。
这是 direct Prompt injection：攻击指令通过用户而非 tool output 或获取内容进入。模型层防御锚定于用户意图；当用户自己输入指令，classifier 没有异常可抓到，人类承包商拿到同一脚本也会照做。
唯一有效防御是环境：egress control 无论意图如何都阻止 POST，filesystem boundary 从一开始就让 ~/.aws 不可达。团队在内部 Slack 分享该 prompt 讨论时，也意识到部分内部 Agent 会读取 Slack，payload 已成为环境中的内容；他们向 thread 加入 canary string，以便发现是否有 Agent 获取它。Agent 读取一切的世界里，调查工具本身也是攻击面。
模式三：本地 VM（Claude Cowork）
Claude Cowork 在用户 desktop 上运行，可访问用户选择的 workspace folder。它面向一般知识工作，而非软件工程，因此平均用户不太可能熟悉 bash。
human-in-the-loop sandbox 策略不能直接迁移：不能期待非技术知识工作者判断 find . -name "*.tmp" -exec rm {} \; 这样的 bash。批准例外若需要普通用户没有的专业能力，管理员就应设定绝对、始终开启的边界。
因此，Cowork 初版运行在平台 vendor hypervisor 提供的完整 VM 中，macOS 使用 Apple Virtualization framework，Windows 使用 HCS。VM 有自己的 Linux kernel、filesystem 和 process table；只 mount 用户选定的 workspace 与 .claude folder，host 其余内容不可见。credentials 保留在 host keychain，永不进入 guest。该设计防范 Claude 未来可能出现 misaligned behavior：被攻陷 Claude 仍能破坏 workspace 内内容，但 architecture 确保那是它唯一能触达的内容，除非用户添加 connector，并且由用户决定 mount 什么。
最初的 full-VM mode 中，Agent loop 也在 guest 内运行，Claude 作为普通 Linux user 运行，甚至不知道自己被 sandbox。与 Claude Code 不同，那里有一个 sandbox 外的 privileged process 决定每个命令是否执行；有说服力的 injected prompt 或疲劳的批准点击，可能令它运行未 sandbox 的命令。Cowork 不存在持有 escape-hatch key 的外层进程，也就没有能授予例外的组件。
Cowork VM 的六项主要隔离机制中，两项在 guest kernel 外强制，即使 Agent 在 VM 内取得 root-level access 也依然存在；其余四项由 guest 强制并特意保持最小，因为外层已承担其余保护。
但 full-VM mode 带来实践问题：VM startup 一旦失败，Cowork 就完全不可用。将 Agent loop 移到 VM 外、仍把 code execution 留在 VM 内，让 Claude 即使 VM 出错仍能回复、协助调试，而不至冻结。因为 VM 仍对 Agent 执行的代码强制 filesystem 和 network control，这一变更的安全影响很小。
本地 MCP server 也被移到 VM 外。放在 VM 内难审计，VM 更新时会产生脆弱依赖，也无法支持需要与数据库等本地 process 交互的 MCP；此类 server 无论如何都要跑在 host。该变化让 Cowork 与 Claude Desktop 的 local MCP 一致：将其视为用户选择安装的软件，交由管理员决定允许哪些 local MCP（如有）。remote MCP 不受影响，因为它们不在用户机器运行。
为精细控制本地文件访问，Cowork 提供 read-only、read-write、read-write-no-delete 三种 mount mode。一个关键细节是 symlink resolution 必须发生在 path validation 之前，否则授权 folder 内的 symlink 可指向外部并逃逸。企业客户可通过 MDM setting 中 mount-path allowlist 进行管理员控制。
遗漏的风险：经批准 domain 的外传
第三方披露给出了一个清晰案例。Cowork egress allowlist 正确允许访问 api.anthropic.com，产品不调用自家 API 无法工作。但攻击者在用户 mount workspace 放入恶意文件，文件含隐藏指令和攻击者控制的 API key。Claude 遵循指令读到 workspace 的其他文件，并用该 key 调 Anthropic Files API。egress proxy 检查 destination 为 api.anthropic.com，于是放行；文件上传到了攻击者 Anthropic account。sandbox 完全按设计工作，但数据仍被外传。
过去，allowlist 被理解为 destination filter，即告诉 Claude“这些 domain 可以访问”。更合适理解是 capability grant：allowlist 中任一 domain 上可达的所有功能都是攻击面。允许 api.anthropic.com 也意味着允许向任意 Anthropic account 上传文件。
修复是在 VM 内部署 defensive man-in-the-middle proxy 来拦截自家 API 流量。它只放行带 VM 自己 provisioned session token 的请求；嵌入攻击者 key 的请求由 proxy 拒绝，并且阻止可启动 server-side fetch 的 header。该 proxy 位于 VM 内而非服务器，因为只有 VM 知道 provenance；对 server 而言，Cowork request 与其他 API client 无法区分。
这再次表明自定义组件常是薄弱处：各产品中的 hypervisor、seccomp 和 gVisor 都可靠，而 custom allowlist proxy 发生了失败。
遗漏的风险：VM 隔离也把 endpoint detection 隔在外面
企业安全团队评估 Cowork 时常问：“为什么我们的 EDR 看不到 VM 内？”答案是，同样限制 Claude 的隔离也限制 host-based endpoint detection and response。对 EDR 来说，Claude Cowork 是不透明 hypervisor process，无法检查 guest。
隔离会降低可见性；对依赖 endpoint visibility 的合规姿态而言，不透明会成为问题。当前缓解方案是通过 pull-based OTLP export 让管理员事后拉取 event log，但这不等于 live monitoring。构建类似系统时，应早期就为这种讨论预留空间。
| 环境 | 短生命周期 container（claude.ai） | HITL sandbox（Claude Code） | 封闭 VM（Claude Cowork） |
|---|---|---|---|
| 隔离开销 | container spin-up | 低延迟 native sandbox | 完整 VM boot |
| 对用户依赖 | 无 | 必须能理解 bash | 无 |
| 影响范围风险 | server-side container（由 gVisor 与 host infra boundary 防护） | local workspace | mounted workspace（由 vsock 与 hypervisor boundary 防护） |
信任 Agent 所读取的内容
企业常问如何保护 MCP connection。问题很好，但正确范围比 MCP 更广：任何提供给 Agent 的外部资源都同时带来两种风险，传统供应链意义上的 code execution 风险，以及 Prompt injection vector。传统 dependency audit，例如 pin version、验证 signature、审查 source，可处理前者，却无法处理后者。
Remote 与 local 的差别比看上去更重要。 本地安装 tool 可审计：可读代码、pin version，也知道不会悄然变化。remote tool，例如 hosted MCP server、cloud connector，在批准后任何时候都可改变行为，安装时的信任决定未必仍适用。Anthropic connector directory以持续审查应对；其外一切都应视作不可信。应先在 fake data、且恶意 tool 影响范围受控的环境中运行。
即使 tool 可信，tool output 也是攻击面。 前述 GitHub README 即是例子：适用于 web page 的输入扫描，也应以同样严谨程度用于 network-enabled tool result。尽管增加延迟且不是完美防御，团队仍倾向 live inspection：一旦被投毒返回引导 Agent 外传数据，日志只会显示一次成功、经授权 API call，事后没有信号可找。
在 Claude Code 和 Cowork 中，tool call 都通过强制 network 与 file policy 的 proxy 路由，且可在返回值进入模型 context 前检查。负责检查的 classifier 可以是小而快的模型，无需承担推理任务。
展望
Persistent memory poisoning。 跨 session 保留的 Agent context 比例持续增长，包括 product memory、CLAUDE.md、mounted workspace，以及 scheduled 与 long-running Agent 的 state directory。注入若落入任一位置，会在每次 Agent 启动时被重新加载。更多 Agent state 存活于 session 之外，意味着经典 post-exploitation 意义上的新 persistence mechanism。session startup classifier 将需更加普遍。
Multi-agent trust escalation。 Subagent 可隔离不可信内容，只向 main Agent 返回 structured fact 而非 raw text；但这也可能被滥用。如果 subagent output 因来自“我们”而被视为比 raw tool result 更可信，就引入新 Prompt injection vector。多 Agent 系统需在分配不同 trust level 与承担 trust escalation 风险之间权衡。
Agent identity。 Cowork 的答案很具体：credential 留在 host keychain，VM 获得每 session、缩小 scope 的 token，并可独立于用户撤销。但更广泛的跨平台 Agent identity 问题仍待解决：Agent 是否应拥有自身 principal identity，还是应作为用户延伸继承用户权限？最终答案可能是二者结合。
随着 Agent 更强，攻击面不断变化。这里见到的失效类型可能在各行业和实验室重演。需要共同投入 Agent 特有安全姿态，包括共享 benchmark、披露规范、共同 identity standard 和跨 vendor red-teaming。本文聚焦 containment，但它仅是 Agent 安全图景的一部分。治理、可观测性及整套体系可参阅 NIST AI agent identity and authorization 项目、由澳大利亚 ACSC 牵头并与 CISA、英国 NCSC 共同发布的六机构 Agentic AI 采用指南，以及 AI 管理标准 ISO/IEC 42001。Glasswing 是 Anthropic 的一项贡献，团队期待与合作伙伴和竞争者共同推进这一关键议题。
总结
Anthropic 不断回到以下原则：
先在环境层设计 containment，再在模型层引导行为。 最具启发性的两个事故，员工钓鱼和第三方 allowlist 披露，都是数据通过被允许路径 egress 的案例。模型层无法帮助，因为它们没有异常可抓；当概率性防御全部漏过时，真正生效的是确定性边界。
隔离强度要匹配用户的监督能力。 能读 bash 的开发者与不能读 bash 的知识工作者，不处于相同 threat model。用户能否评估 Agent 即将做什么，应当决定 containment strategy；两边选错都算失败：对专家摩擦过大，或对非专家信任过多。
警惕自定义组件。 久经考验的 hypervisor、syscall filter 与 container runtime 经受过远多于自建组件的对抗性关注。本文所述部署中，标准 primitive 坚守住了边界，而围绕它们自建的组件暴露出漏洞。
Agent 虽是新类别软件，但其系统级交互并不新：它们仍读文件、开 socket、spawn process。因此，以成熟 tooling 实现 containment 是至关重要、切实可行的防御。AI 演进会持续改变部署的风险收益平衡，但对影响范围设置硬上限，常能把这一平衡推向正确方向。
致谢
本文由 Max McGuinness、Mikaela Grace、Jiri De Jonghe、Jake Eaton 和 Abel Ribbink 撰写。
并感谢 Hanah Ho、Hasnain Lakhani、Pedram Navid、Molly Villagra、Maya Nielan、Akila Srinivasan、Sam Attard、Alfred Xing、Mohamad El Hajj、Gabby Curtis、David Dworken、Adam Jones、Amie Rotherham、Christian Ryan、Lucas Smedley、Brett Andrews 等人的贡献。
特别感谢安全与产品工程团队，以及报告 Claude 产品漏洞的个人和组织。
脚注
- Claude Code auto mode 将命令批准委托给 model-based classifier：它尽量降低摩擦，约 0.4% benign command 会被阻止；代价是仍会漏掉一部分风险命令，约 17% 过度激进行为可通过。因此它是 sandbox 内 defense-in-depth 的一层，而非 sandbox 的替代品。